It is common practice to partition access to system functionality into different access classes, such that members of different classes have different levels of authorization and allowed actions. For example, employees and guests are usually allocated different levels of authorization for an organization's facility and resources.
A problem can arise, especially with remote systems, where some desired action or system access requires a level of authorization not held by anyone present at the system. One possible solution is to wait until a person with the necessary authorization is available, or can be dispatched to the relevant location. Another possible solution is to elevate one of the available personnel to the required access class. Neither of these two solutions may be acceptable or efficient. Sending a person having the necessary authorization to the site takes time, and may be costly. Elevating a locally-available person may be unacceptable because the person to be elevated may be unqualified in terms of knowledge. As another consideration, elevating an on-site person to a higher access class is usually an all-or-nothing action. Even if all that is needed is the ability to carry out one action of the elevated class, the elevated person obtains the authorization to carry out all actions of the elevated class.